%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Iteration 5
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Iteration 5: SWIFT Communication (Av1)}

In the fifth iteration we decomposed the \emph{SWIFT Communication} component to support communication with SWIFT. For this decomposition we consider QaS Av1: "Interbank communication failure". The use cases that are relevant to this are:
\begin{itemize}
	\item UC13: Issue payment with bank card
	\item UC23: Send interbank credit instructions.
	\item UC24: Receive status update for interbank credit instruction.
	\item UC25: Process interbank credit instruction.
\end{itemize}

This decomposition could have been done together with iteration 4: "Interbank Transaction System (P2)" because they are both about interbank communication. We decided to perform two smaller, separate iterations to keep a good overview.


These drivers can be summarized in the following requirements:
\begin{itemize}
 \item SAB should be able to detect interbank communication failure. 
 \item No messages should be lost.
 \item In case of failure, messages are stored and retransmitted later on until success.
 \item SAB should keep track of how long failure remains (in case of external failure).
 \item The operator is notified of failure (when failure is internal).
 \item The operator should redeploy failed components.
 \item SWIFT acknowledges received messages.
 \item SAB has to acknowledge received SWIFT messages.
 \item Status updates of credit instructions should arrive within certain amount of time.
 \item SAB should detect when a status update deadline has passed.
 \item SAB keeps track of credit instruction of which the status update deadline is passed.
 \item Interbank credit instructions are sent out correctly.
\end{itemize}


To satisfy these drivers we considered different availability tactics to find an appropriate solution.
\begin{description}
    % Tactic problem
    \item[Fault Detection:] \hfill \\
    
        \vspace{-5mm} 
        \begin{description}
            % solutions for problem
            \item[Ping/echo or Heartbeat (Internal Component):] The SAB infrastructure should be able to detect the failure of an internal component within 1 minute. A ping/echo or heartbeat system will be needed that can detect failure of an internal component within 1 minute.
            
            \item[Ping/echo (External component):] Sending messages over SWIFT and waiting for the acknowledgments is an implementation of ping/echo. So ping/echo is already implicitly used to detect failure of the communication channel.
            
            \item[Heartbeat (External component):] A heartbeat system can't be used to detect failure of the communication channel because we can't rely on SWIFT to send out a heartbeat.
            
            \item[Exceptions:] Exceptions can be used to detect failure of an internal component as soon as the component is needed.
        \end{description}
        
        
        
        
    % Tactic problem
    \item[Fault Recovery:] \hfill \\
    
        \vspace{-5mm} 
        \begin{description}
            % solutions for problem
            \item[Active redundancy (hot restart):] Active redundancy can be used as a solution to this driver, but it is a costly solution because the whole communication component would need to run in parallel.
            
            \item[Passive redundancy (warm restart):] Passive redundancy can also be used as a solution to this driver. Recovery time will be a bit longer than with active redundancy. The solution is a bit cheaper because the communications channel does not need to be duplicated. The standbys would still need to run and synchronize regularly, making this solution still rather costly.
            
            \item[Spare:] A spare is a third option. The operator will be able to restart the spare and let it be set to the appropriate state. Making checkpoints and logging all state changes needs to be done to be able to restore the spare to the correct state. A spare would take longer (order of minutes) to get up and running than passive or active redundancy, but it would be cheaper because it does not need to run the whole time.
            
            \item[State resynchronization:] State resynchronization can be used to resynchronize active and passive redundant backups.
            
            \item[Checkpoint/rollback:] The failed component should be redeployed and reverted to a previously working state.
            
            
        \end{description}
        


    % Tactic problem
    \item[Fault Prevention:] \hfill \\
    
        \vspace{-5mm} 
        \begin{description}
            % solutions for problem
            \item[Process monitor:] A process monitor can be used to delete nonperforming processes and create new instances of them, initialized to the appropriate state.             
        \end{description}
        
\end{description}






\begin{figure}[!ht]
    \centering
       \includegraphics[width=0.8\textwidth]{images/It5_AV1_componentdiag.png}
    \caption{Component diagram after iteration 5.}
    \label{fig:It5_AV1_componentdiag}
\end{figure}


To handle the requirements in this iteration the \emph{SWIFT Communication} is decomposed into incoming communication components, outgoing communication components and a communication monitor [See figure \ref{fig:It5_AV1_componentdiag}].

The \emph{Incoming SWIFT Communication} will handle all incoming SWIFT messages. It will acknowledge all these incoming messages and route the messages to the necessary components. It will route incoming POS payments to the \emph{POS System} to support UC13, and all incoming credit instruction or status updates to the \emph{Interbank Transaction System} to support UC24 and UC25. The \emph{Incoming SWIFT Communication} will contain a buffer that can hold $200 000$ messages so that no messages will be lost. All incoming and routed messages will be written to the \emph{Incoming Buffer Log} so that in case of failure of the \emph{Incoming SWIFT Communication} the state can be restored and no messages are lost.

The \emph{Outgoing SWIFT communication} will act as a message endpoint for SWIFT messages coming from the \emph{POS System} (e.g. POS payment acknowledgments) to support UC13 and the \emph{Interbank Transaction System} (e.g. credit instruction and status updates) to support UC23 and UC25. It will send all these messages coming from the system to SWIFT and wait for an acknowledgment. Messages are resent with exponential backoff if no acknowledgments are received. Sending messages to SWIFT and waiting for the acknowledgments is an implementation of the ping/echo tactic. This way the \emph{Outgoing SWIFT Communication} component is able to detect failure of the SWIFT communication channel.

The \emph{Outgoing SWIFT communication} will contain a buffer that can hold $200 000$ messages so that no messages will be lost. All incoming and send out messages will be written to the \emph{Outgoing Buffer Log} so that in case of failure of the \emph{Outgoing SWIFT Communication} the state can be restored and no messages are lost.

The \emph{SWIFT Communication Monitor} will be responsible to monitor the communication with SWIFT. It will send out a ping to the \emph{Incoming SWIFT Communication} and the \emph{Outgoing SWIFT Communication} and wait for an echo each minute to see if they are still operational. The \emph{Outgoing SWIFT Communication} will reply in the echo the last known status of the SWIFT communication channel. Failures are notified to the \emph{Operator} which can store them and react to them.

In case of failure of an internal component the \emph{Operator} can redeploy the failed component. In case of hardware failure, a provided spare can be used, this redeployment takes no longer than 2 minutes. The \emph{SWIFT Communication monitor} can restore the state of the components with the use of the \emph{Incoming buffer Log} and \emph{Outgoing buffer log} as soon as the components are redeployed. This restoration of state will take no longer than 5 minutes.

A \emph{Deadline Auditor} that will keep track of all status update deadlines is also provided. Through the \emph{Customer Information} facade, this \emph{Deadline Auditor} is provided with read access to the \emph{Transaction Database} which keeps track of standing interbank transactions. The \emph{Deadline Auditor} checks the status update deadlines each 10 minutes. This way the \emph{Deadline Auditor} can keep track of all credit instruction for which the status update deadline is passed, and it can notice missing status updates at most 10 minutes after the deadline. Missed deadlines are reported to the \emph{Operator}.


Requirements can be divided over relevant components as follows:
\begin{itemize}

	\item \emph{Incoming SWIFT Communication}
	\begin{itemize}
		\item UC13: Issue payment with bank card
		\item UC24: Receive status update for interbank credit instruction.
		\item UC25: Process interbank credit instruction.
	\end{itemize}
	
	
	\item \emph{Incoming Buffer Log}
	\begin{itemize}
		\item Av1: No incoming credit instructions or status updates are lost.
	\end{itemize}
	
	
	\item \emph{Outgoing SWIFT Commmunication}
	\begin{itemize}
		\item UC13: Issue payment with bank card
		\item UC23: Send interbank credit instructions.
		\item UC25: Process interbank credit instruction.
	\end{itemize}
	
	
	\item \emph{Outgoing Buffer Log}
	\begin{itemize}
		\item Av1: Not outgoing credit instructions or status updates are lost.
	\end{itemize}
	
	
	\item \emph{SWIFT Communication Monitor}
	\begin{itemize}
		\item Av1: SAB should detect the failure of an internal or external component.
	\end{itemize}
	
	
	\item \emph{Deadline Auditor}
	\begin{itemize}
		\item Av1: SAB should detect and monitor statues update deadlines.
	\end{itemize}
\end{itemize}














